OpenEdge Development:<br />Progress Dynamics Basic Development Setting instance properties in SDOs

There are references in this material to instance properties that you can set for your SDOs. Instance properties are SmartObject properties or attributes (the terms are synonymous as used in Progress Dynamics). You can assign them as initial values of the object to cause it to act in a particular way, either by default or when it is run in a specific container. In Progress Dynamics, default values for these property values are written to the Repository when the object is created, and then inherited for each occurrence of that object within a container window. You can modify these property values for the object itself, in which case they will be inherited by any use of that object in an application container window. Or you can modify the values for a particular instance, that is, as used in a specific window.

In either case, you can modify these values through the AppBuilder or using the Dynamic properties sheet. This gives you access to all the records in the Repository that define objects. Even though SDOs were static objects in the first release of Progress Dynamics, information about them was stored in the Repository. In particular, instance property settings are defined in the Repository for each occurrence of an object in a container window, and this includes static objects such as SDOs.

Object attributes are defined at several levels. Every object type (such as SDO) defines basic attributes and default values for them where appropriate. Each specific object of that type (such as the Sports database Customer SDO called customerfullo) defines values for other attributes that might not be given values at the object type level. Each instance of an object in a specific container (such as the instance of customerfullo in the dynamic window called custbrowsewin) can override any of those attribute values that are defined as instance properties.

In this section you will go through examples of setting instance properties at all three levels: first for the Object Type SDO, then for a specific SDO, then for an instance of that SDO in a container.

Changes you make to class attribute values will automatically cascade down to existing instances of that class. Where attributes have been explicitly set at object or object instance level, they will not be overwritten. This is very important to keep in mind if you need to modify attributes yourself. If you want to change, for example, the number of rows sent from server to client in each batch for an existing window where that SDO is used, you must change the attribute in that specific instance. If you change the attribute in the object definition itself, it will affect all object instances where the attribute has not explicitly been set for that object or object instance.

From the Administration window, select Object

Object Type Control.

Select Data as the Object Type, then choose Find.

Expand to the next level and select Attributes

RowsToBatch.

This property has a default value of 50, which means that every SDO you create will have a RowsToBatch attribute with the value 50, unless you modify it. If you change this value to 20, it changes that default for every SDO created after you make the change, as shown:

This change is shown mostly to demonstrate the levels at which attributes are defined. Exercise extreme care in making changes at this level because it could change the behavior of your entire application.

From the AppBuilder, select File

Open Object and open the specific object to open from the Open Object window.

Click on the Dynamic Properties icon to open the property sheet for the selected SDO.

Find the attribute RowsToBatch and change the value to 20, as shown:

Close the property sheet.

From the Container Builder, open a folder window where an instance of the SDO exists.

Select the SDO and click on the Dynamic Properties icon for that SDO.

Change the attribute value for RowsToBatch to 20, as shown:

Close the property sheet.

SDO startup

When a SmartDataObject is started from a Progress Dynamics window, the code in the SDO’s constructObject procedure checks to see whether the databases required by the SDO are connected on the client. If they are, then the full SDO (<SDOname>.r) file is run on the client. If the databases are not connected, then the client proxy form of the SDO file (<SDOname>_cl.r) is run on the client. For more information on how the various forms of the SDO are generated and how they are constructed, see OpenEdge Development: ADM Reference . This client proxy form of the SDO contains all of the SDO procedures and functions that do not have any database references, and therefore do not require a database connection. You should view this as the standard arrangement: that there is no OpenEdge® database connection of any kind on the client. Using this standard will put you in the best position to deploy your application in a variety of situations in the future.

When the client SmartDataObject is run, its code checks to see if it has an AppService instance property defined. It then checks to see if that AppService is running locally (meaning that procedures in that AppService should be run in the client process) or remotely. If it is local, then the ASHandle property is set to the local SESSION handle. In later calls, running an internal procedure in the ASHandle will run it in THIS-PROCEDURE, the client-side SDO. If it is remote, the SDO runs the full version of itself (<SDOname>.r) on the AppServer as a persistent procedure and sets the ASHandle property to that remote persistent procedure handle. The SDO now coordinates passing database rows back and forth between client and AppServer.